Modular computer program for managing dynamic pricing information

ABSTRACT

Users of a computer network (e.g., the Internet) can be encouraged to access dynamic pricing information (e.g., bid/ask pricing information for goods/services available in commerce) on the computer network (e.g., collected and maintained by a dynamic pricing system) by distributing to one or more users of the computer network (e.g., by e-mail) a modular computer program (e.g., a Java applet) that displays (e.g., in ticker format) dynamic pricing information collected from the computer network, and presenting to the one or more users of the modular computer program an interactive visual indication (e.g., a hyperlink or glyph) of a user-attractive resource available on the computer network (e.g., a contest, reward program, coupons, etc.). Access to the user-attractive resource can be provided to a user upon sensing that the user selected the interactive visual indication. The stream of dynamic pricing information displayed to users can have a predefined taxonomy, and the users can selectively view different levels of the taxonomy.

The present application is directed to Internet navigation paradigms,data organization, click flows and relationships between the source oforigin of goods in commerce and web sites that display information aboutgoods and services available on the Internet. More specifically, theapparatus and methods disclosed herein provide a new way to organize andprovoke participation in bid/ask or dynamic pricing systems available onthe Internet and private networks through taxonomic, branding,navigational and participatory techniques.

BACKGROUND

Electronic commerce on the Internet generally can be organized into twocategories, database driven applications and indexing or informationportal services. Database driven applications can be further categorizedas either transactional or non-transactional applications. Auction sitessuch as ebay™ are non-transactional database driven applications in thattransactions are external to the ebay system and between third partyparticipants that use the system, i.e., ebay as a web site and on-linecommerce application does not process payment information or requirepayment information to participate in the system. Ebay typenon-transactional systems are a source of dynamic pricing information.

Transactional database driven applications, among others, such as thosedisclosed, in U.S. Pat. No. 5,845,265 to Woolston, provide that a sitemay process payment information associated with the transaction and mayfurther provide surety to the Internet customer that the site isproviding transactional and/or performance assurances about participantsin the system. Transactional database driven applications are also asource of dynamic pricing information.

Both non-transactional and transactional systems are database drivenapplications that contain dynamic pricing information in a database thatis encouraged to rapidly change—that is, the content about the item forsale or offers to buy, or bid are stored in a database and not, forexample, in a static web page format. These systems are dynamic in thatthe database content, for example, a bid at an auction, is or isencouraged to rapidly change. Further dynamic information content isprovided by the transient nature of the dynamic transactions themselves,i.e., an auction for a particular item eventually terminates and bid andask pricing for a particular good or service eventually expires.

The dynamic nature of such database driven web sites present an indexingproblem for the second category of electronic commerce related site suchas the search engine or information portal. Take for example the Yahoo™or Altavista™ search engines which, in general, use web crawlers tosearch the web for indexable content, such as static web pages. Owing,at least in part, to the large and expanding amount of informationavailable on the web, it is understood that its takes even the mostefficient web crawler based system several days to crawl and index theresources on the web. Thus, the problems associated with indexing adatabase driven application are two-fold. First, the database must besubject to a properly formed search request to retrieve the content ofthe database. Second, the content in database driven applications isdynamically changing, i.e., a link to an auction in progress, forexample, may have terminated and may present a dead link soon after asearch system indexes the information. Furthermore, the content of thedatabase presents an instance of dynamic pricing which changes toorapidly for an informational portal to index by conventional methods.

Some attempts have been made to ameliorate the problem of indexingdynamic pricing information, such as allowing individual participants toindex information at the informational portal site to point to dynamiccontent at a database driven application. Another attempt to amelioratethe indexing problem is through private arrangement between theoperators of a database driven application and the informational portalsite to index dynamic content through application program interfaces.This piecemeal approach is not automated outside of privaterelationships, if they exist, and still presents the problem of deadlinks and the like after an auction is complete or a bid dynamicallychanges or expires. Furthermore, the piecemeal solution does not providea systemic way to solve the fundamental problems that arise in indexingand searching for instances of dynamic data.

Another class of web sites, the so-called comparison shopping sites orbots, attempt to address the dynamic content indexing issue by imposinganother layer that purportedly bridges multiple dynamic shopping sites.These sites require a search request be entered at the central site andthe search request is parsed and distributed to multiple sites in apredetermined search format. These sites, thus, purport to make thesearching process more efficient by automatically searching a pluralityof sites. This type of comparison site, however, does not address thefundamental problem of indexing dynamic content to populate searchservices for indexable searching by participants. In contrast, theymerely impose another layer of complexity on top of multiple dynamicpricing systems.

Another class of services that attempts to address the problem ofdynamic pricing information is found in the financial art such as U.S.Pat. No. 5,136,501, to Silverman and assigned to Reuters Limited and itsfamily of related patents. This technology does not address the problemof indexing non-financial instances of dynamic pricing and it does notpresent a consistent navigational or taxonomy scheme to navigate andfind pricing information in a heterogeneous computing environment andfound on the Internet, i.e., the Reuters system uses privaterelationships between the parties to exchange information about dynamicpricing.

SUMMARY

The systems and techniques described here are capable of addressingthese and many other problems presented by dynamic content by placing adynamic navigational taxonomy between dynamic content sources andconventional search engines and, thus, making available a fixed orstable point of reference for indexing by conventional search engineswhile organizing dynamic pricing information into a navigation taxonomy.The present systems and techniques may also employ a taxonomicconcentration feature, e.g., the ability to concentrate dynamic pricinginformation from multiple sources into an organized taxonomy of subjectsto provide a micro-narrow cast of information for a particular good orclass of goods and services that may be of interest to a participant.

The present systems and techniques may also provide a way to establish a“functional brand”—e.g., a function that designates the source of originof a particular class or type of goods and services associated with thefunction, that may co-exist with and enhance famous brands or rapidlyestablish associated niche brands through a consistent functionalbranding scheme.

The present systems and techniques may also provide a new way to employconventional telecommunication switch and routing equipment, e.g.,conventional routers, to massively parallel process dynamic content intoa useful taxonomy of content-sensitive streams of information.

The present systems and techniques may also provide a novel utility formonitoring a particular good or delineated class of goods or services,while the monitored content dynamically changes, and thereby reduce thehit load on the source of dynamic pricing by engrafting apoint-to-multipoint communication structure to efficiently monitor anddistribute information about dynamic content to multiple users.

The present systems and techniques may also provide a novel revenuestream by providing a prioritized way to stream continued bid/askinformation.

The present systems and techniques may also provide a new target channelbased on the subject matter of interest for the distribution ofelectronic coupons and advertisements.

The present systems and techniques may also provide a novel stream ofinformation created by data mining techniques hereafter referred as“broadcast data mining”.

The present systems and techniques may also provide novel loyaltyprograms and contests to keep a participant interested in continuing toparticipate in the system.

The present systems and techniques may also provide a novel way to indexitems for sale that utilize the Universal Product Code (UPC) inventoryand tracking scheme into the new dynamic taxonomic navigation andprovides a further use as a source of information to update conventionalsearch engine databases about the availability and pricing of inventory.

The present systems and techniques may also provide a new way to rapidlycompare pricing or bid/ask information from multiple sources.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 depicts a high level view of how a new navigation dynamic contenttaxonomy may map dynamic content available at dynamic pricing systems,e.g., database driven applications, shown as the circle, through the newnavigational dynamic taxonomy, depicted as the upright triangle, toprovide fixed, stable and indexable points of reference, e.g., URLaddresses and meta-tags, to search engines, as depicted by therectangle.

FIG. 2 may represent a high level view of the taxonomic concentrationfeature of the new navigational dynamic taxonomy. A plurality ofdatabase driven or multiple content sources may be depicted by theplurality of circles on the left side of the figure, which may forexample, be multiple market makers for the same taxonomic item such asan individual stock. The navigational dynamic taxonomy depicted by theupright triangle may map bid/ask or dynamic pricing information from themultiple market makers or electronic markets into a single or pluralityof data streams to provide data concentration from multiple sources,e.g., market or market makers A, B, and C through the navigationaldynamic taxonomy which may provide a context-sensitive or indexablepoint of reference, e.g., a URL address or meta-tags, for output to aparticipant or indexing into a search system represented by therectangle. The method of collecting, classifying and sorting data, asmay be inherent in the system architecture, may concentrate bid/ask ordynamic pricing information for fungible or comparable items into anorganized and concentrated stream of bid/ask information.

FIG. 3 may depict a further high level representation of how thenavigational dynamic taxonomy may provide multiple relationships ornavigation relationships in the navigation taxonomy to map dynamicinformation from a plurality of dynamic pricing systems, such asbulletin board auction systems, electronic retail systems and dynamictrading systems through the navigational dynamic taxonomy, to provide auseful way to locate dynamic content and to provide a way to index thedynamic content into conventional search system as represented by therectangle.

FIG. 4 may depict a navigational taxonomy of the dynamic navigationalsystem. Here, information may be visualized as a tree with many rootsand sub roots. The navigational tree in the dynamic navigational systemhierarchy may start at a high level that displays streaming bid/ask ordynamic pricing information at a category level, such as travel, books,finance, cuisine, electronics, and the like, and by navigating “down”through the taxonomy, the taxonomy may further granularize into topicalclassifications such as travel, where travel may in turn granularizeinto sub-topic classifications such as air carrier tickets, and then toa sub-topical breakout which may further granularize the informationdown to particular brands or a source of origin of goods or servicesthat may be participating in dynamic pricing systems available on theInternet or private networks. The dynamic information displayed at thebrand level, for example, may display streaming bid/ask information froma plurality of bid/ask systems where famous brands may be participatingin a variety of bid/ask systems. By establishing a consistent look andfeel for the display and functionality of the streaming dynamic pricingin a modular computer program called a “navlet”, as described furtherherein, the navlet provider may establish a functional brand whereby thefunctionality of the navlet becomes associated in the consumer's mindwith a source of streaming bid/ask information and a way to navigate andfind sources of dynamic pricing.

FIG. 5 may depict one of the functional branding techniques employed bythe present system, here, functional (e.g., navigational) brands thatmay co-exist and enhance famous brands that are participating or areindexed by the system. FIG. 5 may also depict niche or sector brands asco-existing and being enhanced by the functional navigational brandsthat index the niche or sector brands.

FIG. 6 may depict a functional brand instance or navlet as it may appearat the base of the navigational taxonomy or as linked into anavigational cluster, e.g., a navlet-based navigational portal. Here,navigational linking elements are shown, e.g., the navigation up anddown arrows and the “T” button that may invoke a display of a map of anavigational taxonomy to link each navlet into the navigational scheme.Dynamic pricing information that may point to a particular source oforigin of dynamic pricing, e.g., a URL or URI, is transduced tostreaming information on the dynamic taxonomic instance or navlet. Anelectronic coupon may also be depicted as streaming across the dynamicinstance or navlet. Bid/ask and undock buttons are also depicted on thisdynamic taxonomic instance or navlet which may provide linkage to brandsponsored bid/ask systems or provide a link to a dynamic pricing datarepository.

FIG. 7 may depict an undocked instance of functional branding or navletwhere the streaming taxonomic instance may be undocked from thenavigational taxonomy and framed with independent navigation and filteraids, e.g., a complex navlet.

FIG. 8 may depict a high level overview of how micro-narrow castchannels or a diagram of the data flows which may create a dynamicnavigational taxonomy built on navlets beginning with a concentrationlayer, a first selection or channelization layer, to a broadcast layer,to a subscriber layer, to a filter/alarm layer for a variety ofinformation appliances including a web browser or other computerparticipant applications.

FIG. 9 may depict one way in which to construct a Simple Network AskPacket (SNAP) application layer frame as may be employed by the systemand used by the navlet building block. Taxonomic information may beencoded into a standard switchable or routable address in a formatsupported by conventional routing or switching devices, and the SNAP maybe encapsulated for transport to the SNAP routing or switching fabric atthe nexus of the concentration layer and topical selection layer of thesystem. Encoding the taxonomy into a conventionally supported addressfield of a well-supported protocol may allow the system to economicallyre-purpose commercially available router devices into a massivelyparallel context-sensitive channelization or micro-narrow cast system.

FIG. 10 may depict a further breakdown of one possible SNAP formatfurther encoding taxonomic or meta-data information about the bid/ask ordynamic pricing payload for use with navlets and other applications.

FIG. 11 may further depict one of the many possible taxonomic encodingschemes possible in the system.

FIG. 12 may depict a block diagram of a concentration and channelizationmethod that may be employed by the system.

FIG. 12A may depict a functional block diagram of a control program thatmay be employed by the system.

FIGS. 13A, B, and C may depict methods that may be employed by thesystem to collect information and transport dynamic pricing information.

FIG. 14 may depict a high-level functional diagram and implementation ofthe concentration and channelization layers in a message queuingembodiment of the system.

FIG. 15 may depict a control program that may be employed by the systemto create user-defined and system-defined channels of information thatmay be used by the navlet and other applications.

FIG. 16 may depict a functional block diagram of a way the system mayprocess information abut the location of a dynamic pricing instance toconvert the information for use by a navlet and other applications.

FIG. 17 may depict a functional block diagram of a way the system mayemploy messaging and inter-process communication to update the datadisplayed at a navlet and other applications.

FIG. 18 may depict a diagram of a loyalty and contest program that maybe employed by the system.

FIG. 19 may depict a way the system may allow the transfer of a navletto another location or computer or from one user to another.

DETAILED DESCRIPTION

The system disclosed herein may provide a new way to navigate dynamiccontent by presenting dynamic data in a streaming navigable andrelational format and by building navigational portals based on abuilding block of modular computer programs called navlets. Thus, thesystem may provide an organized way to present categorized and navigableinformation with a new class of application programs built on navlets oremploying a single navlet.

Another aspect of the system is a reduced reliance on, or eliminationof, databases to access, or access indexes or links to, navigablecontent or content subject to rapid pricing changes as may be availableon the Internet or from private networks. Here, for example, the systemmay index content and make it available for access through the dynamicmapping and taxonimizing feature of the system by the re-purposing ofhigh speed routers into a taxonimizing and content providing engine,thereby eliminating the necessity of separately searching informationportals to find instances of dynamic pricing.

Another aspect of the system is its ability to concentrate data frommultiple sources based on a dynamic and navigable way to organize andclassify dynamic pricing based on the content of the information. Here,for example, the system may concentrate bid and ask information frommultiple market makers or markets or auctions into a stream or streamsof organized bid/ask data that is navigable down to a useful, oruser-desirable, stream of data. In one illustrative example, theover-the-counter (OTC) stock market may have multiple market makers ormultiple markets present that maintain different bid/ask prices for thesame OTC stock. The system may place the entire OTC market for stocksinto a navigational taxonomy based on multiple or single threadedcriteria such as industry sector in which the OTC listed companyoperates as taxonomized by Standard Industry Codes (SIC) as published bythe United States Department of Commerce or other well-established waysto organize companies by the respective sectors in which they operate.Here, a taxonomic hierarchy may begin with sector categories followed bysector topics, sector sub-topics, down to individual stocks. Navigatingdown through the hierarchy, the participant may navigate down to aparticular stock of interest. The taxonomic concentration feature of thesystem may provide streaming bid/ask information from the specificidentified stock from multiple markets and multiple market makers in asingle stream of bid/ask information. If the user is buying stock theymay select the most appropriate ask price. If the user is selling stockthey may select the most appropriate bid price.

Another aspect of the system is the ability to program a profile intothe system to monitor specific targeted bid/ask occurrences available atprivate exchanges, public exchanges or database driven applicationsavailable on the Internet or through private networks through a navletqueuing system.

Another aspect of the system integrates a loyalty program to encourageparticipation and use of the navlet.

Another aspect of the system allows one participant to send a navlet toanother participant to further encourage use of the navlet.

FIG. 1 of the system may present a high level overview of the taxonomicnavigation and indexability of the system. Bid/ask or dynamic pricingsystems (the terms bid/ask and dynamic pricing may be usedinterchangeably herein) available on the Internet or on private networksmay be represented by the circle 100. These bid/ask systems may beindependently operated, may provide only participant access, e.g., a webpage output, or may be linked to the dynamic navigational taxonomy viaan application program interface or a system level messaging interface.These bid/ask systems 100 may be retail systems, auction systems,dynamic trading systems or other sources of pricing information. Themapping function 102 may classify bid/ask information available frombid/ask systems 100 into a predetermined or dynamic classificationtaxonomy. Here, the taxonomy may be a predefined generally accepted wayto classify or organize goods and services by category, topic andsub-topic. For example, a consumer electronics product, such as a hometheater receiver with AC-3 decoding, and a source of origin of the goodmay be used to place the home theater receiver into the consumerelectronics category, home theater receiver AC-3 decoding topic, a brandsub-topic and a model number sub-sub-topic to classify the product. Theproduct may further be available at a specific uniform resource locator(URL) or other uniform resource identifier (URI) address at a specificbid/ask system such as hotbuys.com or an auction system such as ebay™.The mapping function 102 may further provide a short name for theproduct such as “Sony RX-200” and extract the bid/ask price for theproduct such as $300 using conventional data parsing techniques orprocessing extensible markup language (XML) tagged information. Theshort name, bid/ask price and URL may be mapped into a navigationdynamic taxonomy 104. The navigation dynamic taxonomy may use predefineddynamic navigational linking to provide a way for participants tonavigate dynamic bid/ask content through category, topic, andsup-topical relationships to locate a data steam of interest. Here, byway of further example, a participant may navigate dynamic streams ofdata from a category such as consumer electronics, to a topic such ashome theater receivers with AC-3 decoding, to a brand sub-topic orsource of origin for the goods such as Sony. Here, the system mayprovide reduced data flows as the taxonomy is navigated by the user tothe lower levels of the taxonomy. Thus, for example, the Sony receiverproduct used in this example may be available as dynamic data as SonyRX-200 $300 at the category, topic, sub-topic and sub-sub-topic or brandlevels. As discussed further below, navigation of dynamic data may beused by applications such as navlets, and additional applications suchas indexing, analysis and search tools. For the purpose of FIG. 1, thedynamic data from bid/ask systems 100 is taxonomy mapped 102 to anavigational dynamic taxonomy 104. The navigational dynamic taxonomy maybe further mapped 106 to provide a fixed URL or point of reference forindexing reference by conventional search engines 108. Here, continuingwith the illustrative example, the dynamic navigational taxonomy for theconsumer electronics, home theater receiver AC-3 decoding, Sony brand,may be indexed to a search engine 108 taxonomy of, for example, consumerelectronics, home entertainment systems, Sony brand. Thus, providing apoint of reference for a search result at a conventional search engine108 to return a reference to a point in the dynamic navigationaltaxonomy 104 that in turn may point to dynamically changing bid/ask datafor the products available on the Internet or in private networks 100.The system may provide this bridge between dynamic data 100 and a searchengine's fixed taxonomy 108 to help Internet participants locate bid/askcontent through conventional search engine techniques.

FIG. 2 may provide a high level diagram of another feature of thesystems, e.g., taxonomic concentration or, put another way, the system'sinherent ability to concentrate bid/ask information from multiplesources of bid/ask information into a navigational dynamic taxonomy.Here, for example, an automobile may be available (e.g., offered forsale) at three distinct markets, auctions or retail establishments,e.g., markets A, B, and C, 200, 202 and 204 respectively. Here, thedynamic navigation system 206 may provide a way to concentrate bid/askinformation from multiple sources such as markets 200, 202, and 204based on a predetermined taxonomic category, topic and sub-topicclassification criteria into an instance of streaming bid/askinformation 208. Here, as in FIG. 1, the navigational dynamic taxonomymay provide a point of reference, a URL or URI 210 and meta-tags forindexing into conventional search engines 212.

FIG. 3 may depict a detailed view of the way the system may mapdifferent types of bid/ask systems and information from systems 300,302, and 304 to the navigational dynamic taxonomy 306. Here,relationships may be depicted by an upright triangle shaped taxonomystarting at a root 308, to a category 310, a topic 312, a sub-topic 314to a sub-sub-topic, brand or source of origin of bid/ask data or goods316. This diagram may also depict the multiple indexing of dynamic datanavigational instances 320 to conventional search engine 322 referencesor points of indexing.

FIG. 4 may depict a way in which the navigational dynamic data may beconceptualized, displayed and navigated. Streaming data may beconceptualized as a river of information. The river of information forone particular taxonomy may begin 400, for example, as all streamingbid/ask information generally available on the Internet. This broadrange of data may be captured 402 and displayed at a web site 404 thatprovides links to categories of bid/ask information such as travel, 406,books, 408, financial, 410, and other categorization level materials.Here, for example, categories of steaming bid/ask information may bedisplayed and utilized by navlets. A navlet may be a small modularcomponent that displays a single stream of information while providingnavigational links to additional streams of data or to web sites builtupon multiple instances of the navlet. In the example depicted,categorization of streaming bid/ask information may be enhanced withnavigational buttons such as a down arrow 466 that may indicate thatfurther granularity of streaming information is available under thisstreaming data or navlet instance, or through visual queues such as aglyph or small picture (e.g., icon) representative of a point in ataxonomic hierarchy. For example, the travel category 406 may provideall streaming bid/ask data available under the category travel 406 in astreaming window of data 480. In another mode of the system, thestreaming data at a category level 480 may represent selected bid/askdata under the travel category. In another embodiment, the category orother levels such as topic or sub-topic levels may be populated withrevenue bearing bid/ask information as discussed in the message queuingembodiment as described further below. From the category level 480 thesystem may provide navigation to finer levels of granularity (e.g., atopic level) through navigational indicators 466 and 468. FIG. 4 maydemonstrate an example navigational taxonomy to a travel topic 418 thatmay display dynamic bid/ask data at the topic level 420. Here, thesystem may display streaming bid/ask information at the topic level, forexample, air-travel 422, hotel rooms 424, automobile rental 426 andcruise travel 428. The system may provide a navigational link 430 totopic level 432. In this example, the system may display bid/askinformation from a particular source of origin of goods, services orcarriage. Here, for example, at the topic level 432 the system mayprovide a brand indication of the source of the bid/ask information. Thesystem may further provide navigation to the sub-topic levels 446 and448. Here, the system may navigate to a branded web site or the web sitedesignated as the source of origin of the branded goods and services446. For example, a famous brand air carrier 446 may participate in thesystem by applying an instance of the navigational dynamic taxonomy 452or navlet at a web site branded by or designated as an on-line source oforigin of the products or services 446. Here, the navigational dynamictaxonomy or navlet may provide a way to navigate “up” 453 from thebranded site into the navigational dynamic taxonomy 432 which may bebuilt with multiple instances of the navlet. The functionality presentedat each instance of the navlet or navigational dynamic taxonomy 452,444, 442, 438, 436, 434, 428, 426, 424, 416, 414, 412, 410, 408 and 406may provide a consistent functionality at each level to build anidentity in the consumers' mind of a source of origin of the functionsperformed by the navlet to establish a functional brand awareness in themind of the consumer. Here, two potential functions that may beidentified in the consumers' mind are the ability to navigate a taxonomyand an indication that the source of origin of goods is participating ina bid/ask or dynamic pricing system.

FIG. 5 may depict a way in which to establish a new type of brandawareness in the consumers' mind, e.g., functional branding.

Functional Branding

Functional branding is a way to associate or otherwise establish thefunctionality of a recurring functional theme with a way of doingbusiness on the Internet. Here, for example, the recurring functionaltheme is the vendors' or customers' participation in a dynamic pricingparadigm such as auctions, market maker models of continuous bid/askpricing, demand driven commerce such as bid.com's dutch auction format,and offer/counter-offer/acceptance type system such as disclosed, interalia, in U.S. Pat. No. 5,845,265, to Woolston. A method for establishinga functional brand may establish a modular computer functionality toindicate participation by a source of origin of goods in a dynamicpricing system, it may build web sites comprising multiple instances ofthe modular computer functionality to display goods or services offeredin commerce and provide the modular computer functionality to a web sitethat displays one or more brands. This may be used to create afunctional brand awareness in the consumer's mind, e.g., a consistentfunctionality that indicates participation in a dynamic pricing systemwhere that functionality is a recurring brand theme of a family of websites. The system may further use the modular computer functionality toprovide navigational links to connect to and from the web sites whichmay use multiple instances of the modular computer functionalityprovided to the web site that displays a brand. The system may furtheruse multiple instances of the modular computer functionality to providea navigational taxonomy of subject matter. The system may furtherprovide modular computer functionality in the navlet that undocks themodular computer functionality from a web site that contains the modularcomputer functionality. The system may further use the navlet orfunctional branding module to provide a way for a first participant toe-mail the navlet to a second participant. The system may further usefunctional branding to establish a loyalty program where the navlet candisplay tokens than encourage entry into contests. The system mayfurther use the navlet or functional branding instances to distributeelectronic coupons.

FIG. 6 may depict an overview of an instance of a navigational dynamictaxonomy or navlet. A single instance of the functional instance of thenavigation dynamic taxonomy or navlet 600 may include navigation aids602, 604, 605 and 622, streaming data denoted as scrolling “ticks” 606,608, and 612, electronic coupon distribution 610 and instances to bid614 on an item and instance to search for ask 616 prices and the abilityto undock 618 the instance or navlet into an undocked window or framethat may provide a browser window with only the navlet displayed. Morespecifically, a navigational aid 602 may be represented by an up arrowthat may indicate or be an active control to navigate up or from a topicor sub-topic level up to the next higher point in a navigational dynamictaxonomy. Here, for example, the functional instance or navlet mayappear at the bottom of a taxonomy at the sub-sub-sub-topic or brandlevel. By clicking on the up navigation 602 control a URL to a topiclevel instance, or one level up in the taxonomy of the system, mayinvoke the execution of a web browser that points to the URL of a webpage or display constructed by multiple instances of the navlet at thetopic level. See, FIG. 4, topic or combined brand level 432. Thenavigation aid or navlet 604 may also provide a control to navigate“down’ through the taxonomy, here again, 604, it may provide a URLpointing to a resource that displays a return that yields an instancethat is further down, e.g., from a topic to a sub-topic level in apredefined or dynamic taxonomy. A further navigational aid on the navletor dynamic instance may be invoked by the “T” control 605 which mayspawn 624 a window 622 that may indicate a text or mixed graphical/textrepresentation of a particular taxonomy navigation scheme. The new orspawned window 622 may provide the ability for the user to select andjump to navigational points in the navigation taxonomy, e.g., web sitesbuilt with multiple instances of the navlet or to web sites with asingle instance of the navlet. Here, for example, the navigationdisplayed in the pop up window 622 may provide text that displays thetaxonomy while providing URL links to jump the user to points in thetaxonomy. The navigational aids may be dynamically programmed by thecontrol type packet or XML tagged messages to the dynamic or navletinstance 600, as discussed further below. Programming of the navigationaid or navlet may be accomplished by loading a register or storagelocation with a URL of the next point in the taxonomy to place thenavlet into the taxonomy.

An instance of dynamic bid/ask information may be depicted at 606, 608and 612. The instance of dynamic bid/ask data may be represented by ashort name such as DC-LAX $350 or 98 Mustang $16,995 or other suchappropriate short names to inform the participant of the type of itemsubject to bid/ask dynamic or fixed pricing and/or availability. Theinstance of dynamic information may stream from right to left across theinstance 600 of dynamic pricing or navlet. In one mode of the system,the bid/ask information may be organized by the level on the taxonomy onwhich the information is displayed, which may provide a further contextfor the short name for the dynamic or availability information toappear. One such taxonomic indexing aid may be provided by a pictogramor glyph that may represent a category or topic in which the dynamicinformation appears. The dynamic pricing, availability or “tick”information may provide a URL or URI address, string or link to point ordirect a web browser or other suitable application to the web address orweb site to retrieve the bid/ask or availability information for theitem that is the subject of the short name.

The instance of the dynamic stream, the navlet of bid/ask information,may be further propagated or populated with electronic coupons 610 oradvertisements, not shown. The electronic coupon 610 may provide a URLlink and access code information to unlock or decode electronic couponinformation to provide support for discount or loyalty programparticipation. In one mode of the system the navlet or dynamic bid/askpricing streaming display may be vertically scaled to support one-halfsized Internet advertising placards. In another mode of the system, thenavlet may detect the horizontal size of the display on which it appearsto horizontally scale the size of the navlet. The system, as discussedfurther below, may distribute Internet advertising and coupons based ontaxonomic, user profile information, or other routable and distributionschemes provided by the system.

The navigation dynamic instance or navlet may provide further activecontrols to participate in dynamic pricing systems as shown by the bidand ask 614 and 616 controls. The bid control 614 may provide a link toa web page that allows a participant to place a “buy at” or limit typeorder to bid into a dynamic pricing system. Here, for example, thenavigational dynamic instance may appear at the sub-sub-topic or brandlevel and the bid control 614 may provide a link to a branded web page632 of a brand participant that is participating in a dynamic pricingsystem. The bid control may provide a link to a brand participatorydynamic pricing system. In another mode of the system, the bid controlmay provide a web page for a participant to place a bid whereby thesystem may post the bid in a bulletin board format and make theinformation available to further system participants. In another mode,the navlet may provide an application layer frame, whose descriptionbelow is hereby incorporated by reference, to encode a bid withtaxonomic or subject matter information that may be subsequently routedto subscribers.

The “ask” control 616 may provide a link to a web page that allows aparticipant to search for “ask” prices 620 from a participating sourceof origin of items or services, or other data repositories such as cachesystems or databases that capture the streaming information. This mayallow a participant viewing the navigational dynamic instance toresearch ask and/or current ask prices at a participating dynamicpricing system with multiple suppliers or to perform a search by passingsource parameters to the participating system linked to the supplier atthe brand level 620. This may provide the system with access tohistorical pricing information or as a way to research availability.This may also provide the system with a unique database architecturewhich dedicates a database to capture data that has been organized bythe taxonomic data streams. Thus, a database may be dedicated to aparticular taxonomic subject and a plurality of databases may beemployed to capture data based on the taxonomically organized data flowswhere each database may be organized to optimize search and retrieval ofinformation based on the taxonomic organization. Here, a search systemfront end may be applied to this database architecture to direct asearch request or to guide a participant to the appropriate database toissue a search into a database dedicated to the subject matter of thesearch.

The navlet instance 600 may provide an undock control 618 to provide anability to quickly undock the navigational instance or navlet from aparticipating web site to create a stand alone frame or application ofthe navigational instance that is separate from the web site or browserapplication. In the un-docked mode, the navigational dynamic instance ornavlet may exist without a browser application or within anappropriately sized browser frame while maintaining contact with aserver that may provide dynamic content for the navigational dynamicinstance or navlet.

The navlet may further provide scrolling tools 615 and 617 to “rewind”or reverse 615 the streaming bid/ask information 614, 616 or speed upthe crawl 617 of the streaming dynamic information from a data buffer inthe navlet.

FIG. 7 may depict an enhanced version of the navlet in an undocked orapplication mode. In this mode the dynamic instance or navlet may be anapplication program specific to the target operating system or aninterpreted language for transportability across operating systemsplatforms such as that provided by the Java programming language. Here,instances of streaming bid/ask or retail information may be framed 700in an application program or enhanced navlet. The application 700 mayprovide an index back to the top of the navigation taxonomy 734, awindow to receive banner advertisements 702, pull down navigation aids704, a filter feature to provide user programmable filter or alarmpreferences 706, standard minimization 708 and close controls 710, acontrol to open windows to additional instances of dynamic streamingdata 736, instances of streaming navigational data 712 and 732, links toanalytical tools 726, navigational aids 712 and 714 as described aboveand incorporated by reference herein, streaming instances of short namesthat link to bid/ask or retail points on the web 720, 722 and 724 andbid/ask controls as described above and incorporated herein 728 and 730.

Turing now to FIG. 8, the system data flow may be depicted as concentricrings of information processing and functions. At the core of the systemmay be a data concentration layer where bid/ask information from theInternet and private networks may be concentrated to a broadcastphysical or virtual broadcast medium. Here, an application layer framingprotocol may be encapsulated to transport bid/ask data to aconcentration layer 800. At the concentration layer, the transportencapsulation may be stripped and the application layer framing protocolmay be placed onto a physical broadcast medium, as described furtherbelow, to concentrate and queue data onto the broadcast medium such asan Ethernet, broadcast ATM, FDDI or SONET or other suitable high speedbackbone that may support point-to-multipoint transmission and, in thepreferred embodiment, flow control the data flow from the send modules.In one mode of the system, the interface between the concentration layer800 and the first selection layer 802 may be a private network orvirtual private network wherein an IP source and/or destination addressfor a UDP packet or other suitable packet type may be assigned anaddress that correlates to the application layer framing protocolencoding to represent an information category for classifying andfiltering data from the concentration layer 800 to a predetermined ordynamic taxonomy of information classification. Thus, the interfacebetween the concentration layer 800 and the first selection or mappinglayer 802 may rapidly sort, classify and channelize bid/ask informationby using an application layer framing protocol that provides broadcastor multicast suitable packets that can be filtered and routed byconventional high speed routers. The first selection layer may thenencapsulate the application layer framing protocol for transport to aplurality of broadcast or multicast protocols such as IPv6 or IPv4broadcast or multicast 806, satellite selection interface protocols 808,a pager protocol interface 810, a television/IP broadcast system 812, orother broadcast layer protocol or functional equivalents 804. The IPbroadcast 806 protocol may use convention IP broadcast or multicasttechniques such as Pv6 multicast or the RTP/RSVP IPv4 protocols suitablefor transport to support point-to-multipoint protocols to subscribe oropen to a multicast session with an IP multicast or broadcast server806. In one mode of the system the IP RTP/RSVP server may beincorporated into the router. A filter/alarm layer application 828 maystrip the transport protocol used by the IP broadcast to process theapplication layer framing protocol and the dual use IP addressingscheme, discussed further below and incorporated herein by reference, tofilter bid/ask data and trigger alarms to alert the user based onpredetermined criteria.

In another use of the system, the first selection/mapping layer 802 maytransport sorted and classified bid/ask data to a broadcast layer 804that may encapsulate and transport the taxonomized data to a clientselection layer 814. Here, the client selection layer 814 may be aconventional search engine that may use the streaming taxonimizedbid/ask data to rapidly update database information 826 with currentdynamic pricing data, thereby providing a way for conventional searchengines to rapidly update dynamic pricing data using the system. Inanother mode, the taxonomic streams of data may be captured by databasesdedicated to each category or of topic of information thereby providinga unique database architecture to support massive data storage ofdynamic pricing information.

In another interface mode of the system, a satellite broadcast filterlayer 808 may be used to select taxonomic bid/ask information at theuplink or land earth station (LES) side of a satellite broadcast path.Here, a client selection application/protocol 820 may be used to selectstreaming bid/ask information at the LES for broadcast to downlinkreceiver applications 830. In an alternative mode, the satellite filterapplication may broadcast popular streaming bid/ask information for anoverlay of an instance or multiple instances of navigation dynamicbid/ask information that may be used with navlets executing on devicesconnected by the satellite transmission.

In another interface mode of the system a TV broadcast/IP broadcast 812carrier may be used to transport streaming bid/ask data to conventionaltelevision or digital television receivers. Here, conventional verticalblanking interval (VBI) communication techniques may provide a carrierfor the streaming bid/ask data or MPEG transport protocol techniques maybe used to provide a data and transport path for the streaming bid/askdata. A TV viewer/subscriber application 824 may be used to execute anavlet to display and navigate the streaming bid/ask content. Afilter/alarm application may be executed in conjunction with the navlet,or integrated in the enhanced navlet, to provide automatic orsemiautomatic filter and alarm conditions for the streaming bid/askcontent. Invoking the bid/ask content may invoke a World-Wide Web (WWW)browser application on the television enhancement device such asprovides by WebTV™ or an integrated browser application as found indigital television receiver/processor designs.

FIG. 9 may provide an example of the novel dual use IP addressing schemethat may be employed by the system. The packet shown in FIG. 9 mayprovide an example of a Simple Network Ask Protocol (SNAP) that may beused by the system and the navlets. The SNAP may be an application layerframing protocol that may be used to communicate between an applicationsource of bid/ask information and a navlet application that may displayand navigate streaming bid/ask information. Here, however, the dual useIP addressing scheme may also provide a mechanism for re-purposing aconventional IP router into a streaming bid/ask categorization, sortingand broadcasting device.

FIG. 9 may depict one example of a suitable encapsulation scheme for usein the system. The SNAP for use in the system may begin with theconstruction of an application layer framing packet that uses a standardunit of IP communication such as a UDP packet to encode informationabout the payload (bid/ask or dynamic pricing data) into the source ordestination data field for the IP header of a UDP packet to place thepacket into a predetermined taxonomy or hierarchal classification ofbid/ask information. Here, taxonomic information, referring to FIG. 11for an example classification scheme, may be encoded into the IP sourceor destination address 902, 904 to provide classification information,e.g., meta-data about the payload, for the payload 406. The destinationor source IP address field may be used to provide additional informationabout the payload such as geography information that may be relevant tothe payload, such as an airport of origination for an air carrier fare910 and flags 912 to specify further information about the payload, suchas expiration time of the bid/ask information. The application layerframe or SNAP may be encapsulated into an IP packet 916 and 918 fortransport to the information concentration layer. After transport 919 tothe concentration layer, the IP encapsulation packet 916 may be stripped920 and the application layer frame or SNAP may be placed into theconcentration layer 926. Here, the taxonomic information encoded in theIP address of the SNAP may be acted upon, directly, by conventional andcommercially available routers to provide a selection of bid/askinformation based on the taxonomic classification, geography and flaginformation encoded in the IP address 922. Thus, the selection 928 ofbid/ask information in the system may use commercially availablerouters, such as those provided by Cisco Systems, Inc., to provide anextremely fast and economical method of concentrating and distributingbid/ask information from a plurality of heterogeneous sources andsorting the bid/ask information into a taxonomy to create a hierarchy ofstreaming bid/ask information. The SNAP IP 930 and Payload 932, nowsorted into a taxonomy scheme, may be re-encapsulated 934 and 936 fortransport to a plurality of navlets or other applications. Here, thesystem may use one or more protocol schemes that support multicast orbroadcast transmission of streaming data. Thus, the system may provide ataxonomic broadcast of bid/ask information that may be navigated bynavlets, or used by other application programs for database injection toprovide a useful and economical way to search and/or index bid/askinformation. The SNAP or application layer frame may use the source anddestination data fields to create an IP pseudoheader, see FIG. 10, toencapsulate UDP packets where the pseudoheader is encoded with taxonomy,geography, flags and other meta-data type information for the UDP datapayload to create SNAP frames for use by the system.

FIG. 12 may depict an embodiment of the system as deployed for use withthe Internet. The system may be organized as a concentration/imposetaxonomy stage 1240, a topic selection or taxonomic organization stage1242, and IP broadcast/IP multicast transport stage 1244, a clientselection or navlet selection stage 1248 and client filter/alarm 1250stage. At the concentration stage 1240, the system may impose a taxonomyonto the plethora of bid/ask information available from a plurality ofbid/ask systems. These systems may include transactional markets 1202,and auction system 1216 or non-transactional system such as auctions andretail systems that do not process transactions 1232. The system mayinput data with send applications 1204, 1218 and 1244. The sendapplications may execute in conjunction with the database systemsassociated with the sources of bid/ask information 1202, 1216 and 1232.The send application may also reside on a server system that probes thedatabases and web pages available at sources of bid/ask information1202, 1216 and 1232. The send application may also reside on a serversystem that probes the database and web pages available at sources ofbid/ask information 1202, 1216 and 1232. The send application 1204, 1218and 1234 may also be integrated into the database systems and thesources for bid/ask information 1202, 1216, and 1232. The sendapplication may retrieve information from the sources for bid/askinformation and place the information into an application layer-framingformat, which in one example discussed above, may be a SNAP format. Thesend application may encapsulate the SNAP frame for transport to theconcentration layer backbone 1220. In another mode of the system arouter or an application external to the send application mayencapsulate the SNAP frame for transport to the concentration layer1220. Such encapsulation techniques are conventionally supported by avirtual private network configuration of a commercially availablerouter. Thus, the system may also support the dedicated transport of aSNAP frame to the concentration layer with a transparent connection modesuch as frame relay and ATM type connections. Thus, in one mode of thesystem the send application may place the SNAP frame onto a virtualprivate network or directly onto a private network that supportsassignment of an addressing scheme that supports taxonomic encoding andother information encoding in the novel dual use mode of the addressfields or packet header as disclosed herein. A plurality of sendapplications may transport, format and encode bid/ask information tosupport the concentration layer.

At the concentration layer 1220, a broadcast backbone or a transportfabric that may natively support point-to-multipoint or broadcasttransmission may be used to queue and concentrate bid/ask informationfrom a plurality of data sources. Here, for example, the input queuesnative to a broadcast fabric such as CDMA (code-division multipleaccess) waits for an open slot for a clear channel on the broadcastfabric. This native queuing and flow control structure may be used bythe system to provide flow control for the send application and/or toconcentrate bid/ask data from multiple sources.

The configuration of the system in its novel re-purposing ofconventional routers may support fault tolerance and scale through theaddition of hardware at the concentration layer in redundant faulttolerance nature of the hardware systems that may be employed in therouters. For example, a dual parallel broadcast fabric backbone 1220 mayprovide fault tolerance and scale by additional broadcast backbonesadding redundancy in the broadcast path and may allow the system toscale and handle a massive data load as data is concentrated onto thebroadcast point-to-multipoint hardware devices to make streaming bid/askinformation available for classification and distribution in a taxonomyof bid/ask information.

The topic selection 1242 layer may use router tables to selectivelybroadcast bid/ask information into a taxonomic broadcast. Here, routertables may be used to selectively mask bid/ask information into ataxonomy broadcast of category, topic, sub-topic and micro-topicalinformation and further into geographical and other encoded filteringformats.

A control program, see FIG. 12A, may be used to program and control theappropriate router tables to mask data into a taxonomy broadcast. Here,for example, a mask or table router entry of 255.200.1.xx.xxx mayrepresent retail.consumer_electronics, which may provide an output ofbid/ask information in the retail.consumer_electronics category. As afurther illustrative example a mask entry of 255.3xx.xxx.xxx mayrepresent retail.appliances. A mask entry of 255.33x.xx.xxx mayrepresent a mask entry of retail.applicances.stove. A mask entry of255.333.xxx.xxx may represent a mask entry ofretail.applicance.stove.gas. A mask entry of 255.333.3xx.xxx mayrepresent a mask entry of retail.appliances.stoves.gas.Viking. Thus, the255.333.3xx.xxx table entry may provide streaming bid/ask information onViking brand gas stoves. A further mask entry in the source ordestination data field of the SNAP or functionally equivalent frame mayfurther mask bid/ask information as, for example, Viking brand gasstoves in the 22xxx zip code geographic area where zip code informationmay be translated into the proper hexadecimal, octal or other addressencoding scheme as supported by the IP addressing format masked byconventional routers. Thus, the programming and updating of mask orrouter table entries in the topic selection 1242 in the conventionalrouters 1208, 1222 and 1236 may provide for different levels oftaxonomical geographical information for broadcast from theconcentration layer 1220. Many different taxonomic or categorizationschemes are supported by the system's novel dual use of IP packet headerfields and the examples given herein are merely illustrative. Thecategory, topic, sub-topic and micro-topic selective section 1242 maypass taxonomized streaming bid/ask information to a broadcast stage1244. As previously discussed and incorporated herein by reference thebroadcast stage may support a plurality of interfaces to providecross-platform connection to the end user applications and navlets.Here, for example, the IP RSVP and RTP protocols may be used to connecta plurality of navlets to the IP broadcast through conventional RSVP/RTPtree structures and control methods across a network of routers thatsupport RTP/RSVP. The client selection stage 1248 may use a navlet thatsupports the client side of the RTP/RSVP IP protocol to connect to an IPbroadcast session provided by the IP broadcast stage 1244. In one modeof the system, IP broadcast and/or RTP/RSVP support may be included inthe conventional router that is utilized at the topic selection stage1242. In this instance, user monitoring and IP broadcast session controlmay be managed, tracked and monitored through conventional routermanagement and tracking packages available with commercially availablerouters. Another mode of the system may require a user to provide loginor profile information at a web page before allowing the user access tothe streaming bid/ask information. As described above, a navlet mayappear as a single instance or multiple instances at a web page and thenavlet may be a modular Java program that may be downloaded and executedby a browser 1212. Here, each navlet may subscribe or connect to thetaxonomic streaming bid/ask informational “channel’ to perform usefulfunctions such as displaying streaming bid/ask information in ahierarchy, analyzing streaming bid/ask information and providing a wayto logically navigate streaming bid/ask information. Another instance ofthe navlet may provide a navlet in an “un-docked” or stand-alone mode.Here, the navlet may provide the useful function of displaying streamingbid/ask information by subscribing to the IP broadcast of taxonomicbid/ask information 1244, providing a way to analyze streaming bid/askinformation and a way to navigate and search streaming bid/askinformation. A client filter stage 1250 may be used to filter and orprovide alarm functionality to the end user or navlet instance 1214 and1228.

Thus, one way to further understand the system is by demonstrating theend-to-end flow of streaming bid/ask information. The streaming bid/askinformation may begin at a dynamic or static pricing, transactional ornon-transactional systems 1202, 1216, and 1232. The send programfunctionality may be used to place information about the bid/ask subjectinto an application layer frame, which may be used by a concentrationlayer/selection stage 1220 and 1242 to concentrate information from aplurality of sources and provide a way to output bid/ask informationbased on a pre-determined taxonomy. Bid/ask information from the sendapplication functionality thus may or may not be encapsulated fortransport to the concentration layer and the bid/ask information may berepeatably selected, depending on the depth of the predeterminedtaxonomy, and router mask table programming, for point to multipointtransmission at the IP broadcast stage 1244. A navlet may connect orsubscribe to an IP broadcast session and receive the bid/ask informationin a stream of bid/ask information at the client selection stage 1248.Here, the client application may further filter the bid/ask information,based on the information encoded in the application layer frame, tocapture or display bid/ask information of particular interest to thesubscriber. The client may “click” on an instance of the streamingbid/ask information which may provide a URL for which a user applicationmay locate through the internet world wide web 1252 a data record in adynamic pricing system that was or is the subject of the instance ofstreaming bid/ask information 1254. In one mode of the system, the URLto the record of the subject of the instance of the streaming bid/askinformation is the payload of the SNAP frame. Here, the information forthe URL may include a short display name, a URL address and parameterssufficient to access the database to invoke the generation or display ofthe bid/ask subject of the SNAP frame. The URL request 1230 may passthrough a packet network such as the Internet 1252 to access the dynamiccontent with a URL string 1254 sufficient to access the appropriatecontent. The dynamic pricing application 1232 may respond with a webpage that displays the high bid or ask price 1258. The user, now at theinterface provided by the dynamic pricing system may respond with a bid1256 to which the dynamic pricing system may accept 1254.

FIG. 12A may depict a functional block diagram of a control system asused by the taxonomic broadcast mode and the message queuing mode of thesystem. A taxonomic broadcast control module 1264 may be used to controlthe router mask tables 1262 and for navlet customization control 1268.Here, for example, the router broadcast control may be used to createmasking tables in conventional routers sufficient to provide a usefultaxonomic broadcast of SNAP-based bid/ask information. The navletcustomization control may provide a unique mask table entry specific toa particular navlet, which may be coordinated with the broadcast control1262 to establish a unique channel for a particular navlet. The navlettaxonomy control 1270 may be used to format XML tagged based messages tonavlets to place the navlet into a dynamic taxonomy. Here, for example,if the system add topic level channels, for example, distinguishingbetween Caribbean, Alaskan and Greek island cruise vacations, the systemmay dynamically program its taxonomy as: create a new mask table entryfor cruises that distinguishes between Caribbean, Alaskan and Greekisland cruises; establish IP broadcast addresses for the additionaltaxonomy, distribute by placing XML based control data onto theconcentration layer fabric that the navlet monitoring the cruisetaxonomy should be programmed to navigate down to a predetermined IPaddress that display navlets receiving the Caribbean, Alaskan and Greekcruise broadcast and that navlets receiving the Caribbean, Alaskan andGreek island taxonomy of streaming bid/ask information should navigateup to a web site that displays the cruise taxonomy. The taxonomy controlmodule may broadcast the taxonomy in use by the system on apredetermined IP channel to inform navlets and other applications aboutthe organization of the taxonomic broadcast.

The system may insert advertisements for display at navlets based on thetaxonomy broadcast or through message queues. Here, for example, anadvertisement designated as corresponding to art, such as anadvertisement for a scheduled auction may be injected into theconcentration layer backbone by creating a SNAP frame that contains theappropriate header taxonomy information and a payload that contains aURL that points to the desired advertising. The data and contest controlmodule may collect account information on the distribution ofadvertising.

The advertisement control module 1274 may also distribute advertisementsby creating a message for use in a channel queue, described furtherbelow, and inserting the advertisements into the channel queue. Here,advertisement insertion in the message queue 1288 may also be encodedwith a time to live (TTL) or predetermined termination time as used byother messages in the queue to provide a time-limited display of theadvertisement at the navlet.

The system may employ communication between the concentration layer 1286and the respective send modules to provide flow control 1280 to therespective send modules. In this mode of the system the send controlmodule 1280 may use conventional IP flow control techniques to provideflow control instructions to the respective send modules.

The system may employ a contest control module 1282 to distributepictogram or glyphs to navlets to encourage participation in contestdesigned to reduce navlet breakage. In the SNAP mode, the system mayencapsulate a contest glyph or a URL that points to a contest glyph inthe payload of the SNAP frame. In the message queue mode, the system mayplace the contest glyph into an appropriately formatted channel messagefor display at navlet(s). Here again the system may encode the contestglyph with a time to live parameter to limit the display of the contestglyph.

Another mode of the system may generate a navigational taxonomy, supportparticipant-designated bid/ask information and function in anenvironment where a navlet may pull information from a server.

FIGS. 13A, B and C may depict functional block diagrams of the sendmodules that the system may employ to collect dynamic pricinginformation.

FIG. 13A may depict a send module that works in conjunction with UPCdata collection systems 1322, inventory systems 1320 and dynamic pricingsystems 1320 to encode data into a SNAP application layer frame tocollect and transport dynamic pricing information to the system. The UPCdata collection system 1322 may be a conventional UPC-based inventorycontrol system as may be employed to track and encode information aboutgoods and inventory. The UPC collection system may be conventionallyintegrated into an inventory system database 1304. Here, the UPC andinventory system may execute in conjunction with a dynamic pricingsystem or provide an interface to receive dynamic pricing informationfrom an external system 1320. The send module 1311 may contain a tableto map UPC codes 1306 to a taxonomy encoding scheme 1308 as may beemployed by the system. Instances of dynamic pricing may be pulled orpushed from the system 1303 with its UPC encoding to identify the itemsubject to dynamic pricing. Facts about the dynamic pricing instance mayalso be pulled or pushed from the system 1303. The UPC encoding may bemapped by the send module 1311 by the UPC/taxonomy mapping table1306/1308 and combined with dynamic pricing information 1314 for inputinto a SNAP encoder 1312. The SNAP encoder may output appropriatelyformed SNAP packets containing a short name (which also may bedetermined and controlled by either the inventory system 1303 or theUPC/taxonomy mapping table 1310), dynamic pricing information and a URLto point to the source of the dynamic pricing information 1320 fortransport to the system's concentration layer 1316. The send module 1311may receive flow control 1312 and table programming information from theconcentration layer and the system taxonomy control module to programand control data flow from the send module 1311.

FIG. 13B may depict a send module that may be used by the system toextract dynamic pricing information from non-integrated dynamic pricingsystems 1324. Here, the send module 1327 may use predetermined subjectmatter based inquiries to form search requests 1330 for input into adynamic pricing system 1324. The subject matter search request may workin conjunction with taxonomy encoding information 1328 to create subjectmatter search requests that correspond to taxonomy information employedby the system. The dynamic pricing system may return information whichmay be parsed, as described herein and incorporated by reference, toextract facts about the dynamic pricing information. The SNAP encodermay receive a short name for the dynamic pricing information. The SNAPencoder may receive a short name for the dynamic pricing instance fromthe subject matter search module 1326, taxonomy information thatcorresponds to the subject matter search and facts about the dynamicpricing instance to encode SNAP messages for transport to theconcentration layer 1336. The SNAP encoder may receive flow control andsubject matter/taxonomy information from the concentration layer and thetaxonomy control program to control the data flow from the send module1327.

FIG. 13C may depict a send module in dynamic pricing system that istightly coupled to the SNAP encoder. Here, the dynamic pricing systemmay maintain a short name, taxonomy information and dynamic pricinginformation for input into the SNAP encoder. The SNAP encoder mayassemble and output the SNAP application layer frame for transport tothe concentration layer 1344. The SNAP encoder may receive flow controlinformation 1346 from the concentration layer to control the data flowinto the system.

FIG. 14 may depict a high level block diagram view of another mode ofthe system. In this mode, a browser 1406 may request one or more pages1404 from a web server 1402 within a taxonomy or as a standaloneinstance of a navlet 1402 whereby the server 1402 may respond to thepage request by providing information 1410 and a download of a navlet1412. The navlet 1414 may issue a request for a page of dynamic pricinginformation 1416 from a server 1420 configured to support the navlet1414. The server 1420 that supports the navlet 1414 may provideinformation about dynamic pricing information, advertisements or couponsin response 1418 to the navlet request 1416. The navlet 1414 may displaythe information received in response to its request for information1418. The response to the navlet 1418 may contain information encodedwith XML tags to govern the further operation of the navlet such asrequest recurrence frequency and taxonomic information to place thenavlet into a taxonomy. The navlet 1414 may request a page again 1416 towhich it may receive a response with new data or control information1418 thereby establishing an update loop between the navlet 1416 and thenavlet support server 1420. The system may support a navlet load factorby providing XML tagged control information to slow or speed up navletrequests 1416.

The navlet support server 1420 may be supported by a processing server1424 that may provide information about the dynamic pricing data anddistribute advertising and coupons and support a loyalty program, asdiscussed further below and incorporated herein by reference. Theprocessing server 1424 may support a plurality of “channels” which maycorresponded to a taxonomic organization of data or to user-profiledpages as discussed further below in queues 1426, 1428 and 1430.Reference to dynamic pricing information may, for example, be popped offa channel queue 1431 and placed into an update queue 1432. Theprocessing server may process information from the update queue 1432 togenerate a request to fetch 1338 information about the dynamic pricinginstance from, for example, an auction system 1442 and retrieve theinformation 1436 in response to the fetch request 1338. The processmessage function may parse the response 1436 to extract facts, such asthe current bid and whether and when the auction has terminated or isscheduled to terminate to update the channel queue 1430 with currentinformation about the dynamic pricing instance 1433. Thus, the processserver may establish an update loop between the channel queue 1426, 1428and 1430 and the update queue 1432 and the process message function 1434to continuously update the dynamic information for display at thenavlet(s) 1414. In one mode of the system the update queues processmessage 1434 channel loop may eliminate redundancies in the updatequeue, thereby unburdening the bid/ask server 1442 of multiple requestsfor the same information and may further provide a queue method andcontrol through providing information that prioritizes information inthe channel queue and update queue and by controlling navlet updatefrequency through the distribution of frequency information through XMLtags to increase the frequency of dynamic pricing data updates, forexample, as an auction nears its predetermined termination point.

As previously described, herein incorporated by reference, the instanceof dynamic pricing information may contain a short name such as “SonyRX-200 $300” and information about the location of the source of originof the dynamic pricing information such as a URL for display at thenavlet 1414. Here, the user 1408 may select the dynamic pricing instanceon the navlet 1414 to provide a way to rapidly link to the source oforigin of the dynamic pricing information 1444 to which the user 1408may receive a response 1446 from the source of origin of the dynamicpricing information 1442 in a URL response 1446.

A taxonomic hierarchy of dynamic pricing information may be provided bya channel programmer 1456 to provide information to populate into pagesthat contain multiple navlets, navigational web pages or a single navletinstance at, for example, the brand or source of origin of goods level.Here, the channel programmer 1456 may submit candidate information,which may be in the form of a URL to a channel programming web server1448. The channel programming web server 1448 may present a browser 1452with a web page of data fields for the channel programmer 1456 to “drop”or input candidate URLs. The candidate URLs may be placed into acandidate queue at the processing server 1424 to provide an input streamto the process manager. Multiple instances of candidate queues andprocesses may exist to support the multiple instances of predeterminednavigational or support channels 1426, 1428 and 1430 whereby the processmessage process may pop a URL from a candidate queue, verify that theURL for the dynamic data can be fetched 1338 and received 1436 toappropriately place the dynamic data instance into the respectivechannel queue.

In another mode of the system, the channel programmer 1456 may bereplaced by a user so that the user may generate a user-specifiedinstance of pricing data. Here, a user 1456 may use a browser 1452 toaccess a web page from a server 1448 to establish a user “channel” byreceiving a web page 1470 that provides data fields for the user toprogram a short name for the dynamic pricing instance and a URL addressof where the dynamic pricing instance is located. The user may alsoreceive a navlet 1472 that points to a web server that services requestsfrom the navlet as described above and incorporated herein, to establishthe loop between the navlet 1454 and the server 1460 to receive 1462 andservice 1464 information request from the server 1468. Here, theuser-designated instances of dynamic pricing data may be submitted tothe candidate queue 1440 which may in turn be serviced by the processmessage process 1434 to parse and retrieve dynamic pricing data asdescribed above. Here, the dynamic pricing data may be placed into thequeue 1458 to generate and establish an update loop as described aboveto service the user-designated instance of dynamic pricing and toreceive the user-designated dynamic pricing at the navlet 1454.

FIG. 15 may depict the user interaction with the web site for acandidate item submission to the navlet server. The system may provide alogon screen 1500 to collect user profile and account information foruse with the system. The system may also provide the logon screen 1500as a way for the system to identify a user logon name or account with auser designated channel of data by providing a relationship between auser logon identification and a URL for a user navlet server page byconventional database entry and tracking techniques. The system mayprovide a web screen for a user to provide logon credentials 1502 whichthe system may verify as valid 1508 or reject and inform the user or thesystem of the invalid logon attempt 1504 and record the attempt 1506which may be used to evaluate whether to terminate additional logonattempts from a particular IP address. The system may establish asession with the user after a valid logon 1510. The system may thenprovide a channel or navlet programming page 1514 for data entry orinteraction with the user. The user may select a form to providesubmission of a URL that points to an instance of dynamic priceinformation 1512 which may display a candidate product submission form1518. The user may then submit the candidate of dynamic pricinginformation to the system 1528. The submission may require a short namefor display at the navlet of the dynamic pricing instance. The systemmay then determine whether the information points to or contains enoughinformation to form a sufficient request 1526. If the submission issufficient the system may accept the submission to create a candidatemessage for the dynamic pricing instance 1534. If the submission is notsufficient the system may inform the user of the insufficiencies 1520and return the user to the display candidate form 1518. The system maythen return the user to the display programming page 1514 to elicitfurther submissions from the user. The system may process the candidateinstance of dynamic pricing information by forming the information forentry into a candidate dynamic instance queue 1539 and the system mayfurther generate a message 1540 that the dynamic pricing instance hasbeen placed into the candidate product dynamic instance queue 1546. Atthis juncture, the system may have collected further information aboutthe dynamic instance, such as the termination date and the time of theauction or the expiration date of an offer for submission of expirationinformation into the candidate queue 1546. The system may accomplishthis data collection function by requiring the information from the userduring the submission process or through the invocation of a parsingprogram at 1540 to collect the expiration or termination informationfrom the source of the dynamic pricing instance. The system may use theexpiration or termination information as a data field in the candidatequeue 1546, which may be subsequently used by the system for queuingpriority and navlet frequency adjustment. Here, for example, the systemmay use the termination date and time for an instance of dynamic pricingat an auction to increase the refresh rate of the system as the auctionnears its termination.

In another mode, the system may display a candidate advertisement formto the system 1516 to a predetermined administrative user of the systemor to general user as a way to collect user profile information and as away for users to place advertisements, distribute coupons or propagategame pieces. User profile information may include what types ofadvertisements or electronic coupons and contests the user has aninterest in participating. Here, the system may allow a user to entercontests as further described below. In the advertisement mode of thesystem an administrative or other user may submit a URL that points toan advertisement 1516 which may be submitted at a URL submission form1522. The system may verify that the submission is sufficient for suchdetails as advertising account and billing information through theverification loop 1532 and 1524. In another mode of the system, theadvertisement submission task may point to a URL for advertisementinsertion by a third party server such as doubleclick™ in which case thesubmission dialog may be replaced with a procedure which specifiesparameters to pass to third party servers. The URL which points to theadvertisement may be placed into a queuing format for use by the system1576 which may in turn place the appropriately formatted reference tothe advertisement into the appropriate system queue 1544 for queuing1548 for subsequent propagation to the appropriate navlet(s). The systemmay also generate a message to indicate the placement of the referenceto the advertisement for system accounting and performance tracking1542.

FIG. 16 may depict a flow diagram for processing messages from acandidate queue to a channel queue. Here, the candidate dynamic pricinginstance 1602 may be removed from the queue 1604 for processing. Thesystem may check to determine whether the URL pointing to the dynamicpricing instance is a valid URL that points to valid data 1606. If theURL is valid the system may fetch a web page that contains the dynamicdata instance 1612 and determine whether the fetch was successful 1614.In another mode of the system the fetch procedure 1612 may be replacedby an application program interface (API) with the database thatcontains the instance of dynamic pricing information by, for example,collecting information from the user, such as a unique itemidentification, that may be used to access the database through an API.If the fetch was successful 1614 the system may parse the fetched pages1616 to extract facts about the instance of dynamic pricing. If theparse is successful 1618 as verified by conventional parsing techniquessuch as range checking the values assigned to data fields, then themessage may contain valid facts about the dynamic pricing instance.

FIG. 17 may depict a block diagram of a data flow that may be used tocommunicate with a navlet. The system may check a channel state 1700 todetermine whether the channel is active, e.g., whether a navlet or otherapplication is in communication with the channel. In one mode of thesystem the channel activity may be determined by calculating thedifference between the times the channel or web page was accessed by anexternal source, such as a navlet. After a predetermined period of timein which the channel has not been accessed it may be declared inactiveand dropped from the update loop. If the channel is active 1704 thesystem may inspect or pop a record from the channel queue 1710. Thesystem may then determine whether the record has aged sufficiently todetermine whether the message requires an update. Here, a data field inthe data record in the queue may be used to determine the terminationperiod for the dynamic pricing instance. If the dynamic pricing instanceis nearing its termination point the system may use this information todetermine 1720 the age of the record and whether the system shouldupdate the record. If the record has aged the system may pop the messagefrom a channel queue 1728 and queue the message 1732 to schedule theupdate of the dynamic pricing instance 1702. The system may pop theupdate message 1706 from the update message queue 1702 and fetch thepage specified by the update message 1712. If the fetch is successfulthe system may parse the page to extract facts about the dynamic pricinginstance 1730. If the parse is successful 1734 the system may use theextracted facts about the dynamic pricing instance to construct aproduct message 1738. The system may then verify that the dynamicpricing instance message is properly formatted and data range check thedata before propagation to a channel queue 1740. The valid message maythen be pushed onto a channel queue 1724 to update the channel page witha new valid message 1726 and 1718. The system may also push the messageonto the channel queue 1736 in a modified FIFO configuration to placethe message of the dynamic pricing instance into an update loop, see1736 and 1708. (The FIFO may be modified to place terminating dynamicpricing instances higher in the queue to speed the system's update ofthe dynamic pricing instance as it nears its predetermined terminationpoint). If the fetch was not successful 1722 the system may declare thedynamic pricing instance invalid 1714, which the system may use to killthe message pointer to the dynamic pricing instance 1716. If the parseof the page of information containing the dynamic pricing instance wasnot successful 1734 the system may declare the dynamic pricing instanceinvalid 1716 and kill the system message pointing to the dynamic pricinginstance 1716.

The system may use a queue control or channel control program, asdescribed above and incorporated herein by reference, to control thedistribution of advertisements and contest tokens in each particularchannel 1742. The system may support multiple instances and queue usedand supported by the system in FIG. 17 to support multiple navlets andchannels.

FIG. 18 may depict one of the many contests that the system may employto reduce navlet breakage, e.g., to encourage continued participation inthe navlet based system. A navlet 1816 may display pictograms or glyphsof objects to encourage interactive participation with the navlet basedsystem. The navlet, here for example, depicts a glyph of a car 1810 anda plane 1812. The glyphs may provide an interactive link to a web pageor system that is executing a loyalty program such as a contest to win acar 1800 or a vacation package 1804. Here the system may require that auser provide user profile information, which may be collected with acontest entry 1822 and 1806. In one mode of the system, the system mayuse information as to how long the navlet has been in operation tocontrol the distribution of contest tokens, e.g., to reward sustainedviewership. In another mode of the system, the system may use taxonomicinformation to distribute targeted contests such as a vacation to NapaValley, Calif. to a navlet connected to a wine or cuisine taxonomy.

FIG. 19 may depict a functional flow diagram of a way the system maysupport the e-mail transfer of navlets between different locations andusers. Here, for example, the navlet 1910 and a first participant orlocation 1900 may contain a control 1904 to e-mail the navlet 1901. Thee-mail control 1904 may pass an argument that contains informationsufficient to identify the page at which the navlet is receivinginformation 1922 or from which IP broadcast or multicast IP address thenavlet is receiving information. The passed information may be used astext information for an e-mail program 1912 designated by user 1900through browser preference controls. The user may then includeadditional text to the e-mail and designate an e-mail address to sendthe navlet. The user may then send the e-mail to another location or toanother user B 194. The user B may receive and open the e-mail 1916 andselect the URL passed by argument from the navlet 1901. The URL mayinvoke a browser 1918 at user B to pass a URL containing arguments to atracking database 1924. The tracking database may respond with a navlet1920 that receives an argument to pull information or “tune,” e.g.,enter a session with, the taxonomic broadcast 1922 that was the datasource for the navlet 1901 at a new instance of the navlet 1902

These and other permutations and uses for the system are readilyapparent to one skilled in the art upon use and disclosure of thedescribed system. Therefore we claim:

1. A method for encouraging users of a computer network to accessdynamic pricing information on the computer network, the methodcomprising: distributing to one or more users of the computer network amodular computer program that displays dynamic pricing informationcollected from the computer network; and presenting to the one or moreusers of the modular computer program an interactive visual indicationof a user-attractive resource available on the computer network. 2-70.(canceled)